This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
While only a decade ago, video content was primarily intended to be watched on TV sets, today, numerous devices could be used instead e.g. portable video players, tablets, smart phones, etc. All these devices have different capabilities (screen resolution, CPU power, battery) and are somehow connected to get access to content. As a result, there is a need to serve these devices with tailor-made content while preferably sharing the same hardware distribution infrastructure.
This is essentially the role of adaptive streaming. In a nutshell, the idea is to have several versions of the content available and to serve the target devices depending on their own capabilities and the current network conditions. Among alternate approaches for adaptive streaming, HTTP adaptive streaming (HAS) is currently the approach receiving most interest. The idea is to have a HTTP server which serves alternate segments/chunks of the video depending on the request of the client. In other words, a video content can be seen as a collection of files (either physical or logical) that can be requested by the client who has access to a manifest.
Traitor tracing consists in serving clients with content watermarked with a unique identifier. If a copy is later found on an unauthorized distribution network, it is then possible to identify the misbehaving customer. While there have been a number of algorithms proposed for conventional video, HAS only received marginal interest.
In the domain of watermarking scheme compliant with HAS, the document U.S. 2013/0166868 discloses a server storing several pre-watermarked versions of each chunk and preparing a client-specific manifest file depending on the client user identifier (UID) so that the client gets a copy watermarked with its UID when the video is served. The main shortcoming of this approach is that it induces significant storage overhead on the server side. Moreover, the solution may be tricky to set in place for systems relying on logical files, e.g. Adobe HDS, Microsoft ISS or MPEG DASH. Besides, this solution induces that the server knows the client UID which raises a liability problem, in other words how to ensure that the server provides good playlist to the right client based on its identifier and even more what if the server is “malicious”. Finally, another drawback of this solution is that individual chunks cannot carry a non-integer number of payload bits. Indeed if a chunk is anticipated to encode N payload bits, the server should store the associated 2^N different pre-watermarked versions of the chunk. This requires N to be an integer number, and a rather small one actually to avoid significant storage overhead. As a result, the watermark embedding rate may be significantly reduced.
In the domain of watermarking schemes, document WO 2013/079632 of the applicant describes a 2-steps bit stream video watermarking system that operates directly in the compressed domain. It is composed of (i) a computationally intensive profiling step that analyzes the bit stream to identify locations that could be possibly modified as well as an alternate value that could be used, and (ii) a blitz fast watermark embedding module that applies this metadata to insert the desired watermark payload. A key aspect of this system is that the two steps can be run at different locations and time, e.g. the preprocessing offline with the metadata stored on the server and the serialization online on the client side. As a result, this solution does not induce any overhead (CPU, storage) on the server side.
Since the video content is now composed of Q different bit streams (1 stream per quality e.g. per bit rate) and that we know how to watermark a single bit stream, a straightforward idea consists in profiling all Q bit streams independently and incorporating in each chunk the corresponding metadata to embed the watermark. Upon reception of HAS video chunks on the client side, the embedding instructions are applied to serialize the chunk with the unique identifier of the client. For forensics investigation, Q detectors are run in parallel (1 detector per forensic metadata i.e. per quality). The watermark information obtained with the quality that yields the highest detection response is then kept for each set of temporally aligned chunks. Finally, the information obtained for all selected chunks is aggregated to recover the hidden watermark payload.
The main issue with this approach is that the embedding rate, in other words, the number of changes performed per second, is highly dependent on the intrinsic properties of the bit stream. As a result, the preprocessing module applied to the Q different bit streams will yield slightly different embedding rates. Since each payload bit 130 is spread over a number of changes in the bit stream, the random switches of HAS are prone to come into the way of the payload modulation strategy as depicted in FIG. 1. Q=4 bit streams 101, 102, 103, 104, associated to Q versions of the video content, are available at the server. Each version subdivided in temporally aligned chunks or segments 100. Each payload bit of the message (e.g. UID) is spread across 5 changes in the bit stream. Each payload bit 110 is represented by 5 elements such as square 111, triangle 112, circle 113 and diamond 114. Each client or viewer receives a collection 121, 122 of chunks 100 corresponding to a random path across the Q versions or qualities in this example. Such random paths are indicated in dashed lines. These random switches intrinsically come into the way of the payload modulation strategy i.e. a payload bit no longer reduces to a series of 5 changes burst as exemplified on the paths corresponding to the collections 121, 122 of chunks. For instance, the path 121 of the first viewer yields 6 changes associated to the first payload bit (square) and only 4 for the second one (triangle). Parallel decoding of the chunks may still be possible but there is no guarantee on the robustness of individual embedded bits. In other words, while this method allows efficient serialization at the client side, it is not compliant with HTTP adaptive streaming for delivering the content.
In summary, known methods for watermarking video either raise the issue of overhead in term of CPU and of data storage on the server side or the issue of the compliance with HTTP adaptive streaming. A method for watermarking video compliant with HTTP adaptive streaming which reduces the overhead (CPU, storage) on the server side is therefore needed.